home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001402_my_limited understanding of HyTime, I believe this is correct -.msg < prev    next >
Text File  |  1994-01-24  |  3KB  |  69 lines
  1. there is no way you could take a document from one HyTime system and
  2. expect to import it into another HyTime system without change.  But the
  3. task is much _easier_ if both systems are HyTime compliant.
  4.  
  5. Let's summarise the advantages and disadvantages of adding HyTime CLINKs
  6. to HTML+.
  7.  
  8. Advantage:
  9.  
  10.  * Easier to import information from other HyTime-compliant systems, or
  11.    from systems which export information in HyTime-compliant format (of
  12.    which there are currently none).
  13.  
  14. Disadvantages:
  15.  
  16.  * Two alternative ways of doing the same thing leads to lack of
  17.    clarity in the DTD.
  18.  
  19.  * Added complexity in browser code (which would have to support both
  20.    styles of link, and wouldn't have a HyTime engine to help - yet).
  21.  
  22. On this one it seems to me that the disadvantages outweigh the advantages -
  23. HyTime CLINKs are not the way to go for HTML+.
  24.  
  25. However, Dale also says:
  26.  
  27. > there are some challenging ideas in [HyTime] that go way beyond linking.
  28.  
  29. Could the ideas in HyTime's measurement module and the concept of a FCS
  30. help in defining hot spots within an image?  There would be no
  31. disadvantages associated with multiple ways of doing things.
  32.  
  33. I'd also like to explore how HyTime constructs could be used to express
  34. synchronisation relationships between documents.
  35.  
  36. On one or two things I want to take issue with Dale:
  37.  
  38. > As
  39. > part of the Davenport Group, I spent more than a year
  40. > investigating HyTime for possible use in Docbook DTD and other
  41. > online publishing activities.  I did not see broad support
  42. > for HyTime, as a standard or as technology.  I
  43. > decided that HyTime was not something to be used by our
  44. > current or next generation of technology. I was also very
  45. > frustrated that HyTime exists only on paper, and so anyone
  46. > can say anything about it without proving it in practice.
  47.  
  48. Did you reject HyTime simply based on these reasons, or were there
  49. specific technical issues which you objected to? If so, I'm interested
  50. to know what they were.
  51.  
  52. The Davenport Group certainly went on to use HyTime in their SOFABED
  53. spec.
  54.  
  55. > However, we should not ignore the absence of HyTime-based technology --
  56. > none was developed to test the specification as part of the
  57. > standardization process. 
  58.  
  59. HyTime-based technology _is_ being developed.
  60.  
  61. HTML+ will need testing and changing before it is finished.  We should
  62. not be afraid to add bits of HyTime to HTML+ if it looks sensible to do so.
  63. If it doesn't work, it can be replaced.
  64.  
  65. Chris Adie                                   Phone:  +44 31 650 3363
  66. Edinburgh University Computing Service       Fax:    +44 31 662 4809
  67. University Library, George Square            Email:  C.J.Adie@edinburgh.ac.uk
  68. Edinburgh EH8 9LJ, United Kingdom
  69.